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1 OBLIVIOUS PROXYING USING A SECURE COPROCESSOR 

2 FIELD OF THE INVENTION 

3 The present invention is directed to the field of 

4 network security protocols. It is more specifically 

5 directed to the field of secure proxying for computing 

6 devices. 

7 BACKGROUND OF THE INVENTION 

8 Network security protocols are used to ensure privacy 

9 and integrity of communication on an open public 

10 network. These protocols are typically intended to 

11 achieve end-to-end security guarantees such that the 

12 communication is private to the entities who establish 

13 the parameters of the secure communication channel. 

14 Figure 1 shows an example of a typical secure 

15 communication between a client 10 and a server 11. The 

16 client and the server establish such a secure 

17 connection 12 by first establishing the parameters of 

18 the connection through a handshake. Here, the client 

19 and server can use any of a variety of protocols for 

20 communication. Typically the client establishes a 
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1 connection with the server through the transport 

2 protocol. Then they jointly establish the parameters 

3 of the secure connection by negotiating the 

4 cryptographic material, if any, to be used to encrypt 

5 the packets of the communication. Typically during 

6 this negotiation phase the peers in the communication 

7 authenticate themselves using one of several 

-8- cryptographic mechanisms. After this negotiation 

9 phase, when the client or the server receives a packet, 

10 it identifies the peer of the secure connection using 

11 the mechanisms of the transport protocol such as socket 

12 number, port number etc. This enables the client to 

13 identify the secure communication parameters to be used 

14 to decrypt or verify the data on the channel used. 

15 Without possession of the cryptographic and other 

16 parameters of this secured communication channel, no 

17 entity can eavesdrop on the contents of the packets. 

18 Thus only the client and server can decrypt data sent 

19 on this channel. This is a normal trust model for 

20 communication between a client and server. 

21 In several applications such as web-browsing, the 

22 client and the server wishing to establish a secure 

23 connection, do so through a proxy. There are several 

24 reasons for this split communication. The proxy is 

25 able to log communications initiated by the client. An 

26 example is the case of a proxy implementing the SOCKS 

27 protocol. Since the network security protocol 

28 generally ensures that the communication is private to 

29 the client and the server, the proxy functions only as 

2 
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1 a gateway. It does not see unencrypted information 

2 flowing through it, and only relays packets to and from 

3 the client to the server. 

4 Figure 2 shows another client-server usage scenario 

5 where the client 10 shown talks to a remote server 11 

6 through a proxy 20, Typical examples of such a 

7 scenario are the cases where the proxy implements the 

8 SOCKS protocol or is a HTTP proxy. In these scenarios, 

9 the proxy is used for several reasons. These include 

10 logging the communications initiated by the client (in 

11 the case of the SOCKS protocol) or using a caching 

12 mechanism wherein the proxy stores commonly requested 

13 information (in the case of the HTTP proxy) . 

14 In the situation shown in Figure 2, the dashed lines 23 

15 indicate that when the client ID establishes a secure 

16 connection with the server 11, this connection is 

17 tunneled through the proxy 20 such that the packets 

18 that flow as part of the communication protocol are 

19 opaque to the proxy 20. This is achieved, for 

20 instance, by encryption of the data flowing between the 

21 client and the server. The proxy 20 can not undo the 

22 encryptions and any other cryptographic mechanisms used 

23 in . the secure connection since it does not possess the 

24 cryptographic material negotiated between client 10 and 

25 server 11 using cryptographic means. In this instance, 

26 the protocol 21 that client 10 uses to communicate with 

27 the proxy 20 is the same as the protocol 22 that the 

28 proxy uses to communicate with server 11. The packets 
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1 in the protocol are relayed by the proxy 20 without any 

2 intervention. 

3 In some application scenarios, where computationally 

4 limited clients wish to connect over wireless or other 

5 links, the proxy may provide the following additional 

6 functionalities: 

7 (a) If the client does not support the same 

8 communication protocols as the server, the proxy acts 

9 as a converter between the protocols the client 

10 supports and those that the server understands. For 

11 example, the client may have the protocols specified by 

12 the Wireless Applications Protocol (WAP) , whereas the 

13 server may support only the protocols of the Internet 

14 Protocol (IP) . 

15 (b) The proxy adapts the content supplied by the 

16 server to fit the constraints of the communication 

17 links and the computational, functional and graphical 

18 constraints of the client. 

19 Figure 3 shows an example of an application scenario 

20 where the client 10 does not support the same 

21 communication protocols as the server 11. Thus, for a 

22 communication link to be established the client 

23 communicates to a proxy 20 using a set of protocols 30 

24 which both the client and proxy support. The proxy 20 

25 then communicates to the server 11 using a different 

26 set of protocols 31 which the server 11 supports. If 
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1 the client 10 wishes to establish a secure connection . 

2 to the server 11, it can only do so by establishing a 

3 secure connection to the proxy which then establishes a 

4 second connection to the server. It is important to 

5 note that in such scenarios, the trust model of Figure 

6 1 does not hold. This is because the proxy 20 has to 

7 translate protocol 30 to protocol 31 and vice versa, 

8 and is thus able to see all the messages that flow 

9 between the client and the server. The scenario 

10 depicted in Figure 3 occurs, for instance, if the 

11 client only supports the protocols specified by the 

12 Wireless Applications Protocol (WAP) , whereas the 

13 server only supports those of the Internet Protocol 

14 (IP) . A typical client is a pervasive computing 

15 device. In this example, due to the considerable 

16 differences in the protocols on either side, the proxy 

17 has to decrypt the data exchanged by the client and the 

18 server in order to forward it to the other side of the 

19 connections. 

20 These requirements of protocol conversion and content 

21 adaptation are orthogonal to the end to end security 

22 requirements which are: to prevent exposure and 

23 modification of content by a third party. It is 

24 therefore advantageous to have a system to provide the 

25 original end to end security guarantees without 

26 modifying the server at the back end. In this way 

27 secure communication is possible even without forcing 

28 the client and server to support a common set of 

29 protocols. 
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1 SUMMARY OF THE INVENTION 

2 It is therefore an aspect of the present invention to 

3 provide a method, apparatus and system wherein the 

4 server embeds at the site of the proxy an application 

5 in a coprocessor which performs the functions expected 

6 of a proxy without requiring modifications to either 

7 the client or the server. This is particularly 

8 advantageous when the coprocessor is a secure 

9 coprocessor which is a hardware device designed to 

10 survive in hostile environments where it may be subject 

11 to a variety of security attacks. .These attacks may 

12 range from attacks to obtain secret information stored 

13 on the coprocessor to attacks used to subvert the 

14 normal functioning of an application executing on the 

15 secure coprocessor. One example of a device which is 

16 particularly suited for use in the system implementing 

17 the invention is a device which conforms to known 

18 tamper resistant standards guidelines. Although, the 

19 invention is particularly useful for secure proxying 

20 involving pervasive computing devices, it is also 

21 advantageous for secure proxying in general computing 

22 devices • 

23 In an aspect of the present invention, the invention 

24 enables embedding an application inside a secure 

25 coprocessor at the site of the proxy to perform 

26 functions such as content adaptation and protocol 
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1 translation. These may be achieved with varying 

2 degrees of the following guarantees: 

3 (a) Given that a certain functionality is 

4 intended and expected of the application executing on 

5 the secure coprocessor, an external agent can neither 

6 subvert nor disrupt the execution of such an 

7 application. 

8 (b) In typical network security protocols 

9 consisting of a client and a server, the trust model 

10 guarantees that an untrusted third party can neither 

11 eavesdrop nor subvert the communication between the 

12 client and the server. 

13 In one embodiment, the same guarantees of such a trust 

14 model are obtained even though communication occurs 

15 indirectly through the application executing in the 

16 secure coprocessor at the site of the proxy. 

17 (c) In some alternate embodiments, the same trust 

18 guarantees are obtained by varying levels of modifying 

19 the server to support the same protocols as the client. 

20 An advantage provided by the method of the present 

21 invention is that it is advantageous that no 

22 modification be required at the client or the server 

23 even if they do not support the same set of protocols. 

24 Another aspect of the present invention is to provide a 

25 means by which a server can securely delegate its 
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1 functions to a coprocessor located in the networking 

2 infrastructure. In a symmetric fashion, the invention 

3 is used as a means for the client to delegate its 

4 functions to the networking infrastructure. Thus in an 

5 embodiment the invention provides a mechanism where 

6 multiple parties (several clients and servers) use a 

7 secure coprocessor in the infrastructure to enforce an 

8 arbitrary trust model without modifications to the 

9 clients or the servers. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

11 These and other objects, features, and advantages of 

12 the present invention will become apparent upon further 

13 consideration of the following detailed description of 

14 the invention when read in conjunction with the drawing 

15 figures, in which: 

16 FIG. 1 shows a typical secure communication between a 

17 client and a server; 

18 FIG. 2 shows a typical usage scenario where the client 

19 shown talks to a remote server through a proxy; 

20 FIG. 3 shows example application scenarios in which a 

21 pervasive computing client does not support the same 

22 communication protocols as the server; 
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1 FIG. 4 shows an example of the oblivious proxying 

2 scheme in accordance with the present invention; 

3 FIG. 5 shows an example of how an oblivious proxying 

4 scheme is used to splice secure connections between a 

5 client and a server in accordance with the present 

6 invention; 

7 FIG. 6 shows an example of a secure store used by a 

8 splicing proxy application to store various information 

9 externally without compromising the security and 

10 integrity of the information stored externally or 

11 violating the trust model; 

12 FIG. 7(a) shows an example of components of a system 

13 to implement the present invention which runs on a 

14 proxy; 

15 FIG. 7(b) shows an example of a flowchart of software 

16 executing on a secure coprocessor in accordance with 

17 the present invention; and 

18 FIG. 8 shows an example splicing together two 

19 connections established using the Secure Sockets Layer 

20 (SSL) protocol in accordance with the present 

21 . invention. 

22 DETAILED DESCRIPTION OF THE INVENTION 
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1 Figure 4 shows an example of a system to implement a 

2 method of the present invention to ensure that the 

3 trust model between the client and the server is not 

4 violated even in the presence of a proxy. In this 

5 figure, the proxy 20 contains a secure coprocessor 40 

6 as shown. The secure coprocessor is generally 

7 implemented in hardware and is designed to survive in 

8 hostile environments. A client 10 wishing to establish 

9 a secure connection to a server 11, establishes a 

10 secure connection 30 which terminates at the proxy. A 

11 software component which resides on the proxy forwards 

12 the packets to the application in the secure 

13 coprocessor 40 without encryption/decryption. The 

14 coprocessor 40 processes the packet by decrypting it, 

15 performs transformations on the contents as dictated by 

16 protocols 30 and 31, and then forwards the contents 

17 along a secure connection 31 that it has established to 

18 the server. In one embodiment the system includes the 

19 secure coprocessor 40 and two pieces of software. One 

20 piece of software runs inside the coprocessor 40 and 

21 one runs outside on the proxy 20.- Figures 5 , 6, 7(a) 

22 and 7(b) show the system in greater detail. In 

23 particular, Figures 7 (a) and 7 (b) show flowcharts of 

24 the . functioning of the different software components. 

25 Although, the invention is particularly useful for 

26 secure proxying involving pervasive computing devices, 

27 it is also advantageous for secure proxying in general 

28 computing devices. 
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1 It is particularly advantageous when the coprocessor 

2 shown in Figure 4 offers a high level of security 

3 against a variety of attacks which can range from 

4 physical or other attacks designed to extract secret 

5 cryptographic material stored in the coprocessor, to 

6 attacks designed to subvert the normal functioning of 

7 an application executing on the secure coprocessor. It 

8 is particularly advantageous to use prescribed 

9 guidelines known to those skilled in the art to achieve 

10 a desired level of security against physical and other 

11 attacks, 

12 A coprocessor, typically, is a device which can be 

13 added as a peripheral device to a computer. It 

14 communicates with the host computer using either the 

15 Peripheral Component Interconnect (PCI) or the Personal 

16 Computer Memory Card International Association (PCMCIA) 

17 interfaces. Typically, they are designed to offer 

18 tamper resistance through a variety of means including 

19 physical tamper resistant shields and software 

20 components which guarantee the integrity of 

21 applications running inside the coprocessor. Since 

22 they are typically designed for use in high security 

23 environments they offer, either through software or 

24 hardware, a wide variety of cryptographic primitives 

25 which are also used in common protocols for secure 

26 communication. 

27 In order to implement the scheme described in our 

28 invention, the server and/or the client, according to 

29 the dictates of their/its security policy, designs one 
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1 or more of the applications described and physically 

2 embeds the coprocessor along with the application at 

3 the site of the proxy. A coprocessor can be used in a 

4 wide variety of configurations depending on the 

5 security model that one needs to implement for a 

6 client-server application* For instance, the 

7 coprocessor could be deployed at the site of the proxy 

8 where the proxy is not trusted by either the client or 

9 the server but the tamper resistance of the coprocessor 

10 makes it impervious to security attacks by the proxy 

11 (or any other party) thereby enabling the client and 

12 the server to trust the application executing in the 

13 coprocessor. 

14 Another issue relevant to the method of the present 

15 invention is a scheme for the client to discover a 

16 particular proxy which can securely splice connections 

17 to a given server with which the client wishes to 

18 securely communicate. Various embodiments are used 

19 which depend on the actual transport mechanisms that 

20 are used in the communication between the client and 

21 the proxy and those between the server and the proxy, 

22 there are several schemes to achieve this. For 

23 instance, if the transport mechanisms are based on the 

24 Internet Protocol (IP) this is accomplished by the use 

25 of special ports on the secure coprocessor which are 

26 reserved for the particular server. Although the issue 

27 of client finding the right proxy to communicate 

28 securely with a given server is a very important one, 

29 the invention is described without considering this 
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1 issue. This is because the system implementing the 

2 invention is assumes that the proxy which splices 

3 connections to the server is known to the client. It 

4 should be apparent to those skilled in the art that 

5 given a particular transport protocol, any available 

6 mechanism may be used to discover the particular proxy 

7 which can securely splice connections to a particular 

8 server. 

9 Figure 5 expands on Figure 4 to show an embodiment of 

10 the invention used in a scenario which requires a proxy 

11 20 to splice secure connections between a client 10 and 

12 a server 11. The secure coprocessor 40 contains a 

13 splicing proxy application 50. This application 50 is 

14 designed to translate between secure connections 

15 established with protocol-1 30 and a secure connection 

16 established with protocol-2 31. It is important to 

17 note that the functionality expected of the proxy is 

18 done by the splicing application 50 on the secure 

19 coprocessor 40. There is no change to either the 

20 server 11 or to the client 11. The usual trust model 

21 which guarantees that no one other than the server 11 

22 and the client 10 is privy to the contents is enforced 

23 since a third party can not subvert the application 50 

24 running inside the coprocessor 40. 

25 Figure 6 shows another embodiment of the splicing proxy 

26 application from Figure 5. In this figure, in addition 

27 to the components described in Figure 5, there is a 

28 secure store 60 used by the splicing proxy application 
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1 50. In order for the splicing proxy application 50 to 

2 splice two secure connections, it stores various 

3 information in the secure store 60. The information 

4 generally includes such things as the current state of 

5 the connections, the parameters negotiated in these 

6 connections, the state of the translation process etc. 

7 Since a secure coprocessor is a typically a small 

8 device, it has limited memory and can not store this 

9 information for all the connections. It is 

10 advantageous for this information to be stored 

11 encrypted using any of the common encryption 

12 algorithms, with a key unknown to the proxy 20. This 

13 store 60 is either co-located with the proxy 50 on the 

14 same machine or it may reside on a different machine. . 

15 The proxy 20 uses an information retrieval mechanism 61 

16 to retrieve information from the store. 

17 Figures 7(a) and 7(b) show flowcharts for an example 

18 embodiment of the system components to implement our 

19 invention. Figure 7(a) shows a flowchart, usually 

20 implemented in software, of a component which executes 

21 on the proxy. This component is intended to implement 

22 the transport related functionalities and also to 

23 interface between the application running in the 

24 coprocessor and the parties to the communication. 

25 Figure 7 (b) describes the functionality' implemented by 

26 the application residing in the secure coprocessor. 

27 In these figures, the protocols between the client and 

28 the proxy and those between the proxy and the server 
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1 are not explicitly described and the flowcharts 

2 describe how to implement generic protocol splicing. 

3 There are steps performed in these flowcharts which are 

4 dependent on the actual communication protocols between 

5 the client and the proxy and those between the proxy 

6 and the server* Although the description of these 

7 steps is done in a generic manner, later we will 

8 indicate two instantiations of these steps to splice 

9 concrete protocols such as the Secure Sockets Layer 

10 (SSL) protocol of the Internet Protocol suite and also 

11 the protocols of the Wireless Application Protocol 

12 suite. In the description of the steps to implement 

13 the invention we do not consider any content 

14 transformations other than formatting the data in the 

15 packets of one protocol to that of the other protocol. 

16 It should be apparent to those skilled in the art that 

17 with simple modifications of the software components in 

18 the secure coprocessor described in the figure one can 

19 implement more general content transformations. 

20 As shown in Figure 7(a), the component running on the 

21 proxy essentially functions as the interface of the 

22 application running inside the coprocessor to the 

23 external world. Its functionality is to open transport 

24 connections to the client and the server, read and 

25 write values to the secure store on behalf of the 

26 coprocessor application and to forward packets along 

27 the two connections. 
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1 Step 710 describes the beginning of the splicing 

2 operation. It starts when the proxy software receives 

3 a connection request from the client at the transport 

4 level. For protocols such as the Transmission Control 

5 Protocol (TCP) , the connection request is the usual 

6 socket connect. For unreliable transport protocols 

7 such as the User Datagram Protocol (UDP) , this step is 

8 the receipt of the first communication packet from the 

9 client. . 

10 In Step 711, an entry is created in the storage module 

11 which identifies this client communication. Later, as 

12 directed by the coprocessor application, this entry 

13 will also be bound to the communication to the server. 

14 In fact, the application in the coprocessor often uses 

15 this entry as a mechanism for bookkeeping on the 

16 splicing process. For instance, it uses this to store 

17 the session parameters for the secure communication 

18 between the client and the proxy, and likewise for the 

19 communication between the proxy and the server. In 

20 some other embodiments, such as when the coprocessor 

21 application is splicing communication between 

22 unreliable protocols, or when it wishes to aggregate 

23 packets to perform content adaptation, this entry is 

24 used to store a plurality of packets that are received 

25 or sent so far, partial results of the content 

26 adaptation process etc. In abstraction, we refer to 

27 this entry as the state of the splicing process. Since 

28 exposure of this state may result in violation of the 

29 communication privacy, in general the coprocessor 
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1 application will encrypt the state using any of several 

2 cryptographic means. 

3 The loop shown in steps 712 through 720 is executed 

4 for every packet that the proxy receives from either 

5 the client or the server. Upon receiving a packet from 

6 either the client or the server as shown in step 712 it 

7 computes an id of the sender of the packet (steps 713 

8 and 714) . It then uses transport level mechanisms to 

9 identify the particular communication and retrieves the 

10 state of the current splicing which is stored in the 

11 storage module (step 715) . For instance, if the 

12 communication protocols were TCP, then the source 

13 addresses and the port numbers through which this 

14 packet is carried on can be used to retrieve the 

15 particular entry. 

16 In Step 715, a 3-tuple consisting of this retrieved 

17 state, the id of the sender and the actual received 

18 packet, is formed and forwarded to the coprocessor 

19 application. In Step 717, the proxy then waits for a 

20 response from the coprocessor application. As we 

21 describe later, in step 754 (Figure 7(b)), upon 

22 receiving the 3-tuple from the proxy, the coprocessor 

23 application generates a response which includes a 

24 directive for the proxy application, based on the 

25 3-tuple and the requirements of the splicing process 

26 for these communication protocols. 
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1 In Step 718, the proxy application executes the 

2 directive in the response generated by the coprocessor 

3 application. For generic communication protocols, the 

4 following are examples of the responses and directives 

5 within these responses. Since we have abstracted away 

6 details of the actual communication protocols in this 

7 embodiment, we only discuss possible generic responses. 

8 Examples include: 

9 (a) Terminate the splicing process: This response 

10 is typically generated when the coprocessor wishes 

11 to terminate splicing of this communication. This 

12 ends the proxy application for this client as shown 

13 in step 721. 

14 Note that the proxy handles a plurality of clients, in 

15 parallel, using the same steps shown in FIG. 7 (a) . 

16 (b) Open connection to the server: This directive 

17 is to open a transport connection to the server. 

18 (c) Forward one or more packets to either client or 

19 server. 

20 (d) Close the transport connection to client and/or 

21 the server. 

22 (e) NULL response where no further processing is 

23 required for this packet. 
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1 In alternate embodiments, the coprocessor application 

2 may generate a plurality of responses which include 

3 directives. In such embodiments, the proxy application 

4 will execute each of the directives sent by the 

5 coprocessor application. 

6 After generating the response with the directive, the 

7 coprocessor application typically computes a new state 

8 based on the previous state and the processing it 

9 deemed fit for this packet. If the response 719 is not 

10 to terminate, a new entry is passed back to the proxy 

11 and in step 720 the proxy application replaces the 

12 entry in the storage module with this new entry. If 

13 the response 719 is to terminate, the process ends 721. 

14 Figure 7 (b) describes the functionality implemented by 

15 the coprocessor application. In this embodiment we 

16 only show how to implement generic protocol splicing. 

17 It should be apparent to those skilled in the art, how 

18 with modifications, a similar application can be 

19 designed to perform content transformations. 

20 The sequence of steps executed by the coprocessor 

21 application are as follows. In step 750 it starts with 

22 the receipt of the 3-tuple which is sent by the proxy 

23 application as described in step 716. This 3-tuple is 

24 the id of the sender of the packet (client or server) , 

25 the state (which as we described is usually encrypted) , 

26 and the packet which was received by the proxy. In 

27 step 751, the coprocessor retrieves the encryption key, 
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1 if any, which is used to encrypt the state of the 

2 splicing process. In Step 752, it decrypts the 

3 encrypted state component of the 3-tuple using the key 

4 retrieved in step 751 to obtain T, which is the actual 

5 state of the splicing process. 

6 As discussed before, T typically contains session 

7 parameters associated with the secure communication 

8 along the two links and any other state information 

9 that is deemed relevant to the splicing of the two 

10 protocols. Using the session parameters, depending on 

11 the protocol, in step 753, the coprocessor application 

12 may decrypt the encrypted packet P. In Step 754, 

13 depending on the protocols spliced, the previous state 

14 information in T and the new packet that was decrypted 

15 in step 753, the coprocessor application generates a 

16 response including a directive for the proxy 

17 application. Possible responses may include one of the 

18 following directives: 

19 (a) Forward a newly computed packet Q to either the 

20 client or the server: This response is used in the 

21 simple case when the proxy application is used to 

22 splice similar protocols and the splicing process 

23 only involves decrypting the packet received in step 

24 753 and re-encrypting the packet according to the 

25 session parameters of the other link. In this 

26 application, the state information T could contain 

27 the session parameters of both links. 
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1 One particular embodiment is when the coprocessor 

2 application is splicing two similar protocols, for 

3 example when the communication between the client and 

4 the proxy uses the TCP protocol secured by the Secure 

5 Sockets Layer (SSL) protocol and so is the 

6 communication between the proxy and the server. In 

7 this case, the first few packets from the client to the 

8 proxy are used to negotiate the session parameters 

9 (also known as the handshake packets) for secure 

10 communication as dictated by the SSL protocol 

11 [SSL}. In this stage, the newly computed packet is the 

12 response to the handshake packet received* On 

13 receiving the first handshake packet, the coprocessor 

14 application also generates a response which includes 

15 the directive of opening a TCP connection to the server 

16 and another response which includes the directive of 

17 sending the initial handshake packet to the server. 

18 After the handshake phase, when the session parameters 

19 are committed to, the coprocessor application stores 

20 the session parameters in the state. Once the 

21 handshake phase is complete, the server and the client 

22 send encrypted packets to the proxy and upon receiving 

23 each packet from the sender, the coprocessor 

24 application decrypts in step 754 using the appropriate 

25 session parameters, and computes the new packet Q which 

26 is the decrypted packet, now encrypted with the session 

27 parameters of the other link. The directive in this 

28 case, is to forward this to the receiver. 
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1 (b) NULL response: This response is used, for 

2 example, when the coprocessor application wishes to 

3 aggregate a number of packets before processing or 

4 if the dictates of the communication protocols do 

5 not prescribe any possible action at this instant. 

6 In this case as we shall see in step 755, the 

7 coprocessor may simply aggregate the received packet 

8 into the state T. 



9 For example, one possible embodiment is the case where 

10 the coprocessor application is performing the function 

11 of splicing between the protocols of the Wireless 

12 Application Protocol (WAP) suite and those of the 

13 Internet Protocol (IP) suite. WAP is particularly 

14 useful for secure proxying involving pervasive 

15 computing devices. In the WAP suite, in the session 

16 protocols such as WTP, the packets are carried over an 

17 unreliable transport mechanism (UDP) . One particular 

18 embodiment is the splicing of the communication between 

19 the proxy and the client which is a transaction 

20 protocol of WAP such as the Class 0 or Class 1 

21 transaction, secured by the dictates of the Wireless 

22 Transport Layer Security, with the communication 

23 between the proxy and the server which is done over the 

24 Transmission Control Protocol secured by the dictates 

25 of the Secure Sockets Layer protocol. In this case, 

26 the packets sent by client to the proxy may arrive out 

27 of order or be lost in the communication link. Thus, 

28 when the coprocessor application decrypts a packet, it 

29 may be out of sequence. In this case, it adds this 
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1 decrypted packet to the state and issues a NULL 

2 response. Later, when missing packets arrive, it can 

3 retrieve the sequence of packets it received from the 

4 state T. Thus, reliability as dictated by the 

5 transaction protocols of WTP can be implemented. 

6 In another embodiment the coprocessor application 

7 performs adaptation of content from the server. 

8 Typically content adaptations require the proxy to 

9 aggregate several packets before it can perform 

10 transformations. Upon decrypting the packet, if enough 

11 packets have not been received to perform adaptations, 

12 the coprocessor application can add this packet to the 

13 state and generate a NULL response. When enough 

14 packets, have been received, it can retrieve all the 

15 previously received packets from the state T and 

16 perform adaptations. At that stage, the coprocessor 

17 application can generate the response of forwarding the 

18 (encrypted) result of the adaptations to the client. 

19 (c) Terminate response: used to halt the splicing 

20 process. 



21 (d) Open connection to server: Generated upon 

22 receipt of the first packet from the client or the 

23 initial connection request. 

24 (e) Close connections to the client and/or the 

25 server. 
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1 After generating the response, in step 755 the 

2 coprocessor application computes a new state to be 

3 stored as dictated by the communication protocols and 

4 the embodiment. In step 756, if necessary, it encrypts 

5 this new state. In steps 757 and 758 it forwards the 

6 response including the directive and the new state 

7 respectively to the proxy application. 

8 In the embodiments described so far, the trust model 

9 enforced by the coprocessor was secure communication 

10 between a client and server. As depicted in Figure 8, 

11 the techniques mentioned in this invention can be used, 

12 in the abstract, to delegate to the infrastructure the 

13 task of enforcing more general trust models between a 

14 plurality of clients 80 and servers 81, by embedding an 

15 application at the coprocessor 82 at the site of an 

16 untrusted proxy. The figure shows a secure coprocessor 

17 application which is part of the infrastructure and 

18 enforces an arbitrary trust model between the set of 

19 clients and servers. Each client or server can trigger 

20 events expected within this trust model to the 

21 coprocessor based application and this can enforce the 

22 trust model. The secure coprocessor application can 

23 physically be anywhere on the networking infrastructure 

24 and need not be physically resident on any of the shown 

25 clients and servers. 

26 It is noted that this invention may be used for many 

27 other applications. It provides a general mechanism 

28 wherein a secure coprocessor is placed in the 
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1 infrastructure can enforce any arbitrary trust model as 

2 required by the set of parties to the computation. The 

3 descriptions in the figures are primarily shown for the 

4 case when the trust model requires secure communication 

5 between a single client and server. Although the 

6 description is made for particular arrangements and 

7 applications, the intent and concept of the invention 

8 is suitable and applicable to other arrangements and 

9 applications. For example, the types, sizes and shapes 

10 of the protocols used in the communication between the 

11 client and the proxy, the number of clients and servers 

12 in the trust model and the actual trust model between 

13 these client (s) and server (s) can easily be 

14 accommodated by choosing the right combination of 

15 application on the coprocessor, the content 

16 transformations affected by the application on the 

17 secure coprocessor and the state that is maintained in 

18 the secure storage mechanism. Thus, although 

19 embodiments described refer to a 3-tuple, other 

20 embodiments can generally employ an n-tuple for the 

21 specific communication, where x n' may be any number 

22 suitable to the specific application, not just three. 

23 It will be clear to those skilled in the art that other 

24 modifications to the disclosed embodiments can be 

25 effected without departing from the spirit and scope of 

26 the invention. 
27 
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